Subject: Flow Control SIG Status (Shannon's 8/12 note)

From: [email-masked]
Date: Wed, 18 Aug 93 09:28:51 EDT

Shannon,
I thought your summary of the outstanding issues was excellent - we
should be able to make good progress following that outline.  I'd like
to respond to a few points raised, plus add one new issue.

1) Buffer allocation
   I do have some thoughts about statistically managing buffers, but I
   think that defining how this should be done is beyond the scope of
   our "architecture".  I'm glad we're having the pre-allocate versus
   statistical discussion, since it has ramifications about whether the
   architecture needs to include such features as RESET/RESET ACK.  But
   I think the wording of our eventual new standard should say only if
   we require pre-allocation or not, and if we have something like
   RESET, general guidelines to prevent its misuse.  The rest is imple-
   mentation-specific.	I think the discussion about which general
   approach to pursue will hinge on buffer space requirements - I will
   try to find time to put out an analysis on this and maybe this will
   need to include an example statistical approach to compare with
   yours.  But it would be just that - an example and not part of the
   proposal per se.

2) Pacing responses
   I think we should focus on what the problem is here...  I threw out
   the URGENT data idea very tentatively as a possible response to a
   possible problem of deadlock.  If as you suggest there is no
   deadlock problem then let's focus on the performance issue.  Perhaps
   someone could describe a traffic scenario where interleaving IPMs
   with reverse-flowing traffic will be bad.  Then we can all evaluate
   if it's serious enough to warrant an out-of-band channel.

3) Transport connections
   This is a nit, but I wanted to point out a difference in terminology
   usage.  When I proposed definitions a while back, a TC was a generic
   concept for "pipe between partners".  It might consist of 1 or 2 TCP
   connections, and provided a way to talk about flow control issues
   without worrying about the 1 versus 2 issue.  In your wording, TC is
   the same as TCP connection.

4) Connectionless traffic
   If we were voting on this, I'd vote to include UI-frames in the
   pacing scheme (contrary to my initial proposal).  So unless someone
   disagrees, let's drop this one as an issue and concentrate on the
   other stuff.

5) 6611/RFC 1434 interoperability
   Absolutely this should be a goal.  It was on my "to do" list to
   raise this and suggest an approach.	I still plan to do so, but if
   others have thoughts please feel free to submit them.

As for the new issue, you may remember that my initial proposal was
based heavily on APPN session-level adaptive pacing.  When I made it,
I was focusing on the best technical solution and it didn't occur to
me until after the fact that IBM may have a patent on some of these
concepts.  I checked and indeed there is a 1988 U.S. patent titled
"Adaptive Session-Level Pacing", number 4,736,369.  I looked over the
claims at the back of the patent and frankly it's very unclear to me
whether even a bit-oriented pacing scheme such as the one we started
with might not infringe this patent.  The problem is, it's almost
impossible to say without serious legal analysis whether a given
adaptive pacing scheme would or would not infringe.

Given this, I think our siglet should just move ahead on the technical
issues Shannon outlined and not get distracted by possible legal rami-
fications of our positions.  I personally will not base my opinions on
any hidden motive to broaden the use of IBM patents, but will continue
to stick to purely technical considerations.

Since AIW rules for intellectual property are not in place, as far as I
know my putting the proposal out has no legal significance.  All of our
companies have some discussions to go through about how we will treat
intellectual property.  I know that different standards groups work out
different arrangements in this area, and I wouldn't want to speculate
on what the AIW or SIG (if it becomes separate) will come up with.
Until new agreements are worked out, I understand that the normal IBM
open licensing policy would apply to this patent.  Again, I assure you
that this was not some pre-meditated scheme to lock people into needing
IBM patents - it was just one technical person thinking about technical
and not legal issues.

If people want to discuss the intellectual property law issue, I'd like
to suggest using the aiw-dlsw-sig mailing list, since this is a general
issue related not just to flow control.

Thanks,
Peter